وقتی ارسال صورتحساب الکترونیکی ناموفق می‌شود، اولین واکنش بسیاری از کاربران فشردن دوباره دکمه ارسال است. این کار همیشه امن نیست؛ اگر درخواست نخست ثبت شده ولی پاسخ به نرم‌افزار برنگشته باشد، ارسال تکراری می‌تواند صورتحساب دوم یا شماره تکراری ایجاد کند. راه درست این است که ابتدا شناسه درخواست، شماره منحصر به فرد مالیاتی و آخرین وضعیت ثبت‌شده را بررسی کنید.
متن خطا در نرم‌افزارهای مختلف یکسان نیست. بعضی برنامه‌ها پیام رسمی سامانه را کامل نمایش می‌دهند و برخی آن را به عبارتی کوتاه مانند «خطای نامشخص» تبدیل می‌کنند. به همین دلیل این مقاله به‌جای فهرست‌کردن کدهایی که ممکن است با نسخه رابط تغییر کنند، خطاها را بر اساس علت اصلی دسته‌بندی می‌کند: اطلاعات صورتحساب، هویت و حافظه مالیاتی، محاسبات، ارتباط فنی، زمان ارسال و وضعیت صورتحساب مرجع.
پیش از هر اقدام: خطا، هشدار و وضعیت در انتظار را جدا کنید
هر پیام ناموفق به معنی رد قطعی صورتحساب نیست. سه حالت اصلی را از هم تفکیک کنید:
۱. خطای اعتبارسنجی: سامانه یا نرم‌افزار داده را نپذیرفته و باید فیلد مشخصی اصلاح شود.
۲. خطای ارتباطی: درخواست ارسال شده اما پاسخ قطعی دریافت نشده است؛ ابتدا باید وضعیت استعلام شود.
۳. وضعیت پردازش یا هشدار: صورتحساب ممکن است ثبت شده باشد ولی هنوز پردازش، انتقال به کارپوشه خریدار یا واکنش او کامل نشده است.
| وضعیت | نشانه | اقدام اول | کار پرریسک |
| رد/نامعتبر | پیام مشخص درباره فیلد یا قاعده | متن کامل پاسخ و فیلد را ثبت کنید | تغییر حدسی چند فیلد |
| در حال پردازش | شناسه درخواست وجود دارد اما نتیجه نهایی نیست | استعلام وضعیت و انتظار کنترل‌شده | ارسال فوری نسخه دوم |
| Timeout/بی‌پاسخ | ارتباط قطع شده و نتیجه نامعلوم است | استعلام همان شماره مالیاتی | فرض‌کردن عدم ثبت |
| پذیرفته با هشدار | صورتحساب ثبت شده ولی نیازمند پیگیری است | اثر هشدار و کارپوشه را بررسی کنید | ابطال بدون تشخیص |
برای هر رخداد، زمان، کاربر ارسال‌کننده، نسخه نرم‌افزار، شناسه درخواست، شماره مالیاتی و متن کامل پیام را نگه دارید. تصویر صفحه به‌تنهایی کافی نیست؛ داده خام پاسخ، در صورت دسترسی، برای پشتیبانی فنی بسیار مفیدتر است.
مسیر سریع عیب‌یابی در پنج مرحله
گام اول: وضعیت را استعلام کنید
پیش از ارسال مجدد، با همان شماره منحصر به فرد مالیاتی یا شناسه پیگیری، وضعیت را در نرم‌افزار، شرکت معتمد یا کارپوشه بررسی کنید. اگر صورتحساب پذیرفته یا در حال پردازش است، ارسال دوباره متوقف شود.
گام دوم: مشخص کنید خطا محلی است یا از سامانه آمده
اگر نرم‌افزار پیش از برقراری ارتباط خطا می‌دهد، مشکل معمولاً در فیلدها، تنظیمات یا تولید فایل است. اگر درخواست ارسال شده و پاسخ فنی دریافت شده، متن کامل پاسخ و شناسه درخواست را ثبت کنید. اگر هیچ پاسخی نیامده، اتصال و وضعیت درخواست قبلی باید بررسی شود.
گام سوم: اطلاعات پایه را با نسخه جاری تطبیق دهید
هویت فروشنده، شناسه یکتای حافظه مالیاتی، نوع و الگوی صورتحساب، شناسه خریدار، شناسه کالا یا خدمت، نرخ، تاریخ و محاسبات را کنترل کنید. مقرره رسمی تصریح می‌کند اقلام اجباری و اختیاری باید مطابق الگوی صورتحساب و اسناد فنی جاری در نرم‌افزار پیاده‌سازی شوند.
گام چهارم: رابطه سند را بررسی کنید
برای اصلاحی، ابطالی یا برگشت از فروش، صورتحساب مرجع باید وجود داشته باشد، متعلق به همان فروشنده باشد و رابطه مجاز با سند جدید برقرار شود. تغییر برخی اطلاعات ممکن است با صورتحساب اصلاحی قابل انجام نباشد.
گام پنجم: فقط پس از تشخیص، اقدام اصلاحی انجام دهید
خطای داده را با اصلاح فیلد و ایجاد درخواست کنترل‌شده رفع کنید. خطای ارتباطی را با استعلام وضعیت و جلوگیری از ارسال تکراری مدیریت کنید. در اختلال گسترده نیز مدارک رخداد و تکلیف ماده ۱۲ قانون را جدی بگیرید.
خطاهای هویت فروشنده و حافظه مالیاتی
شناسه یکتای حافظه مالیاتی فعال نیست یا با فروشنده تطابق ندارد
هر حافظه مالیاتی باید شناسه یکتای اختصاص‌یافته از سوی سازمان داشته باشد. اگر شناسه غیرفعال، اشتباه، مربوط به شعبه دیگر یا ناسازگار با پرونده فروشنده باشد، ارسال می‌تواند رد شود.
راه‌حل: شناسه حافظه را از تنظیمات قابل اتکا و کارپوشه کنترل کنید؛ کپی دستی از فایل قدیمی یا شرکت دیگر را کنار بگذارید؛ شعبه، نقش کاربر و پرونده مالیاتی مرتبط را تطبیق دهید. اگر اخیراً حافظه یا روش ارسال عوض شده، وضعیت فعال‌سازی را پیش از صدور دسته‌ای بررسی کنید.
اطلاعات هویتی فروشنده با پرونده هم‌خوان نیست
اختلاف در شناسه ملی یا اقتصادی، کد شعبه، کدپستی یا نقش فروشنده می‌تواند سبب خطا شود. گاهی اطلاعات نرم‌افزار از پرونده‌ای قدیمی خوانده می‌شود.
راه‌حل: منبع اطلاعات پایه را مشخص کنید و داده‌ها را با کارپوشه و پرونده جاری تطبیق دهید. اصلاح فقط در قالب خروجی، بدون اصلاح منبع اصلی، باعث تکرار خطا در صورتحساب بعدی می‌شود.
خطاهای شماره منحصر به فرد مالیاتی و امنیت
شماره مالیاتی نامعتبر یا تکراری است
شماره منحصر به فرد باید مطابق قالب رسمی و با اجزای مرتبط با حافظه مالیاتی تولید شود. استفاده دوباره از شماره قبلی، الگوریتم ناقص یا ساعت سیستمی نادرست از دلایل رایج خطاست.
راه‌حل: شماره را دستی تغییر ندهید. الگوریتم تولید شماره، شناسه حافظه، شمارنده و زمان سیستم را بررسی کنید. اگر پاسخ ارسال قبلی نامشخص است، قبل از تولید شماره جدید، وضعیت همان شماره را استعلام کنید.
امضا، کلید عمومی یا تنظیم امنیتی پذیرفته نمی‌شود
در ارسال مستقیم، داده باید مطابق دستورالعمل فنی جاری امضا و ارسال شود. کلید اشتباه، تعویض کلید بدون به‌روزرسانی تنظیمات، قالب نامعتبر یا ساعت ناهماهنگ می‌تواند احراز اصالت را مختل کند.
راه‌حل: زوج کلید و شناسه حافظه را با محیط درست تطبیق دهید؛ تاریخ انقضا یا تغییرات تنظیمی را بررسی کنید؛ کلید خصوصی را در تیکت، پیام‌رسان یا فایل عمومی ارسال نکنید. برای آزمون، از داده غیرحساس و مسیر پشتیبانی امن استفاده شود.
خطاهای نوع، الگو و فیلدهای اجباری
نوع یا الگوی صورتحساب با معامله سازگار نیست
هر الگو فیلدهای اجباری و قواعد ویژه خود را دارد. انتخاب الگوی پیمانکاری، طلا، صادرات یا فروش عمومی بدون داده‌های متناسب می‌تواند خطا ایجاد کند. استفاده از نوع دوم یا سوم نیز اطلاعات خریدار و مسیر اعتبار را تغییر می‌دهد.
راه‌حل: ابتدا ماهیت معامله را تعیین کنید، سپس نوع و الگوی فعال را انتخاب کنید. برای جزئیات انتخاب نوع و الگو، مقاله مستقل ردیف ۱۴ تقویم محتوا مرجع داخلی این خوشه است. در نرم‌افزار، نسخه الگو را با آخرین مستند رسمی هماهنگ کنید.
فیلد اجباری خالی یا قالب آن نامعتبر است
پیام ممکن است به طول بیش از حد، نوع داده نادرست، کاراکتر غیرمجاز یا خالی‌بودن فیلد اشاره کند. فاصله اضافی، ارقام فارسی/لاتین نامتناسب یا جداکننده اشتباه نیز گاهی مشکل می‌سازد.
راه‌حل: نام فنی فیلد را از پاسخ استخراج کنید؛ مقدار خام را ببینید؛ طول، نوع داده، اجباری‌بودن و قالب را با نسخه جاری سند تطبیق دهید. اصلاح نمایشی در فرم کافی نیست؛ خروجی نهایی ارسالی باید کنترل شود.
خطاهای خریدار
شناسه خریدار نامعتبر یا ناسازگار است
در صورتحساب نوع اول، اطلاعات خریدار باید با نوع شخص و قواعد شناسایی سازگار باشد. وارد کردن شناسه شخص حقوقی در فیلد نامتناسب، رقم اضافی یا اطلاعات پرونده بسته می‌تواند خطا دهد.
راه‌حل: نوع خریدار را کنترل و شناسه را بدون حدس از مدارک معتبر دریافت کنید. از ساختن شناسه جایگزین برای عبور از اعتبارسنجی خودداری کنید. اگر خریدار مصرف‌کننده نهایی است، نوع صورتحساب را دوباره ارزیابی کنید.
صورتحساب در کارپوشه خریدار دیده نمی‌شود
این وضعیت همیشه خطای ارسال نیست. ممکن است نوع صورتحساب فاقد اطلاعات خریدار باشد، شناسه اشتباه ثبت شده باشد، پردازش کامل نشده یا خریدار کارپوشه دیگری را بررسی کند.
راه‌حل: پذیرش صورتحساب از سمت فروشنده، نوع سند، شناسه خریدار و زمان پردازش را کنترل کنید. سپس خریدار باید کارپوشه و دوره درست را ببیند. قانون برای واکنش خریدار از تاریخ درج در کارپوشه مهلت سی‌روزه مقرر کرده است؛ این مهلت را با مهلت ارسال فروشنده اشتباه نگیرید.
خطاهای شناسه کالا یا خدمت و نرخ
شناسه کالا یا خدمت پذیرفته نمی‌شود
شناسه ممکن است نامعتبر، غیرفعال، اشتباه یا نامتناسب با فیلد باشد. استفاده از شناسه قدیمی ذخیره‌شده در نرم‌افزار نیز محتمل است.
راه‌حل: شناسه را از مرجع رسمی جاری استعلام کنید، کش یا فهرست نرم‌افزار را به‌روز کنید و واحد اندازه‌گیری و شرح را با شناسه تطبیق دهید. شناسه عمومی را صرفاً برای عبور از خطا جایگزین نکنید؛ انتخاب باید با واقعیت کالا یا خدمت سازگار باشد.
نرخ مالیات با شناسه یا وضعیت مؤدی سازگار نیست
نرخ درج‌شده ممکن است با شناسه انتخابی، معافیت کالا/خدمت یا وضعیت فراخوان مؤدی هم‌خوان نباشد. رأی و بخشنامه‌های مرتبط نشان می‌دهند اشخاصی که مجاز به اخذ مالیات نیستند، نباید با نرخ دلخواه مبلغی از خریدار مطالبه کنند.
راه‌حل: نرخ را از تنظیمات دستی عمومی برندارید. وضعیت فراخوان، ماهیت کالا یا خدمت و نرخ مرتبط با شناسه را در تاریخ معامله کنترل کنید. اختلاف‌های پرونده‌ای باید پیش از صدور با کارشناس بررسی شوند.
خطاهای مبلغ و محاسبات
جمع ردیف‌ها با مبلغ کل سازگار نیست
اختلاف میان مقدار ضربدر نرخ، تخفیف، مبلغ پس از تخفیف، مالیات و مبلغ نهایی از پرتکرارترین خطاهای داده است. گرد کردن در سطح ردیف و سند نیز می‌تواند اختلاف ایجاد کند.
راه‌حل: ترتیب محاسبه را مطابق سند فنی جاری اجرا کنید؛ اعشار و قاعده گرد کردن را یکسان نگه دارید؛ جمع ردیف‌ها را پیش از ارسال دوباره محاسبه کنید. مبلغ کل را دستی برای تطبیق ظاهری تغییر ندهید.
مقدار منفی یا تخفیف نامعتبر است
برای کاهش معامله قبلی نباید همیشه ردیف فروش جدید با مقدار منفی ساخت. برگشت از فروش، اصلاحی و ابطالی هرکدام رابطه و قواعد خود را دارند.
راه‌حل: ماهیت تغییر را مشخص کنید و از موضوع صورتحساب درست استفاده کنید. اگر اصل معامله حذف شده، صرفاً تخفیف صوری ثبت نکنید. سند مرجع و محدودیت فیلدهای قابل اصلاح را کنترل کنید.
خطاهای تاریخ و مهلت ارسال
تاریخ صدور نامعتبر یا ساعت سیستم نادرست است
تاریخ آینده، منطقه زمانی اشتباه، ساعت ناهماهنگ سرور و تاریخ ناسازگار با معامله می‌تواند سبب رد یا ثبت در دوره نامناسب شود.
راه‌حل: ساعت سرور و نرم‌افزار را با مرجع زمانی معتبر همگام کنید؛ منطقه زمانی را ثابت نگه دارید؛ تاریخ تجاری معامله را با تاریخ تولید داده مقایسه کنید. تغییر دستی ساعت برای عبور از کنترل، زنجیره شماره‌ها و اسناد را مخدوش می‌کند.
فاصله صدور تا ارسال از حد مجاز عبور کرده است
بر پایه مصوبه‌ای که در رأی شماره ۲۳۱۳۰۲۶ دیوان عدالت اداری بررسی و ابطال آن رد شده، از ۱۴۰۳/۰۸/۱۵ حداکثر فاصله تاریخ صدور تا ارسال و ثبت، ۱۲ روز اعلام شده است. در عین حال تنظیمات و دستورالعمل‌های فنی می‌توانند به‌روز شوند و باید در روز اقدام کنترل شوند.
راه‌حل: صدور و ارسال را تا پایان دوره به تعویق نیندازید؛ صف ارسال روزانه و هشدار تأخیر داشته باشید؛ تاریخ معامله را برای دور زدن مهلت تغییر ندهید. اگر تأخیر رخ داده، وضعیت حقوقی و مسیر ثبت یا اصلاح را پرونده‌محور بررسی کنید.
خطاهای صورتحساب مرجع
صورتحساب مرجع پیدا نمی‌شود یا رابطه مجاز نیست
در اصلاحی، ابطالی و برگشت از فروش، شماره مرجع باید معتبر، متعلق به همان جریان معامله و قابل استفاده برای موضوع انتخابی باشد. مرجع اشتباه یا سندی که قبلاً ابطال شده می‌تواند رد شود.
راه‌حل: وضعیت آخرین زنجیره سند را استعلام کنید، نه فقط نسخه ذخیره‌شده در حسابداری. شماره مرجع، فروشنده، خریدار، الگو و موضوع را تطبیق دهید. اگر چند اصلاح انجام شده، سند معتبر فعلی مبنا قرار گیرد.
| خانواده خطا | علت محتمل | کنترل کلیدی | اقدام امن |
| هویت/حافظه | شناسه غیرفعال یا پرونده/شعبه نادرست | فروشنده، شعبه و حافظه فعال | اصلاح منبع تنظیمات |
| شماره مالیاتی | قالب ناقص، تکرار یا ساعت نادرست | شماره قبلی و وضعیت ارسال | تولید طبق قالب رسمی |
| امضا و امنیت | کلید یا پیکربندی ناسازگار | زوج کلید، محیط و ساعت | به‌روزرسانی امن؛ عدم افشای کلید |
| نوع و الگو | الگوی نامتناسب با معامله | ماهیت معامله و نسخه الگو | انتخاب الگوی درست |
| فیلد اجباری | خالی، طول/نوع یا کاراکتر نامعتبر | نام فنی و مقدار خام فیلد | اصلاح خروجی نهایی |
| اطلاعات خریدار | نوع شخص یا شناسه ناسازگار | مدرک و کارپوشه خریدار | عدم ساخت شناسه صوری |
| شناسه کالا/خدمت | نامعتبر، قدیمی یا غیرفعال | مرجع رسمی جاری و واحد | همگام‌سازی فهرست |
| نرخ مالیات | تعارض با شناسه یا وضعیت فراخوان | تاریخ معامله و وضعیت مؤدی | کنترل حقوقی پیش از صدور |
| محاسبات | جمع، تخفیف، مالیات یا گردکردن متفاوت | محاسبه ردیف و کل | اصلاح فرمول؛ نه مبلغ نمایشی |
| تاریخ و ساعت | آینده، منطقه زمانی یا دوره نادرست | ساعت سرور و تاریخ معامله | همگام‌سازی زمان |
| مهلت ارسال | عبور از فاصله اجرایی جاری | تاریخ صدور/ارسال و دستورالعمل روز | ارسال روزانه و بررسی پرونده |
| سند مرجع | مرجع نامعتبر یا زنجیره اشتباه | آخرین وضعیت مرجع و موضوع سند | انتخاب رابطه مجاز |
| ارتباط/Timeout | پاسخ نرسیده یا دسته ناقص است | شناسه درخواست و استعلام ردیفی | جلوگیری از ارسال تکراری |
خطاهای ارتباط، قطعی و پاسخ نامشخص
قطع ارتباط یا Timeout پس از ارسال
Timeout فقط می‌گوید پاسخ در زمان مورد انتظار دریافت نشده؛ ثابت نمی‌کند درخواست ثبت نشده است.
راه‌حل: ارسال خودکار تکراری را متوقف کنید؛ شناسه درخواست و شماره مالیاتی را استعلام کنید؛ لاگ زمان و پاسخ را نگه دارید. اگر وضعیت ثبت‌شده پیدا نشد، طبق سیاست کنترل تکرار نرم‌افزار اقدام کنید.
اختلال گسترده سامانه یا شرکت معتمد
ماده ۱۲ قانون پایانه‌های فروشگاهی و سامانه مؤدیان، با اصلاح ۱۴۰۴/۰۴/۰۸، مقرر می‌کند اگر صدور به علت حادثه یا نقص فنی ممکن نباشد، مؤدی تا پایان روز اداری بعد موضوع را از طریق کارپوشه یا مسیر اعلامی به سازمان یا شرکت معتمد اطلاع دهد و فروش‌ها را طبق دستورالعمل ثبت کند.
راه‌حل: زمان شروع و پایان اختلال، تصویر پیام، لاگ فنی، شماره تیکت و فهرست فروش‌های متاثر را نگه دارید؛ اعلام نقص را در مهلت قانونی انجام دهید؛ پس از رفع اختلال، صورتحساب‌ها را طبق دستورالعمل جاری ارسال و وضعیت آنها را کنترل کنید. صرف گفتن «سامانه قطع بود» بدون مدرک و اعلام، جایگزین تکلیف قانونی نیست.
ارسال دسته‌ای ناقص یا چندباره
اگر بخشی از دسته پذیرفته و بخشی رد شده باشد، ارسال دوباره کل فایل ممکن است تکرار ایجاد کند.
راه‌حل: نتیجه را در سطح هر صورتحساب تفکیک کنید؛ پذیرفته‌ها را قفل کنید؛ فقط موارد ردشده را پس از اصلاح و با سیاست شماره‌گذاری درست بازپردازش کنید. گزارش مجموع بدون جزئیات ردیف برای تصمیم کافی نیست.
چگونه با پشتیبانی فنی مکاتبه کنیم؟
به‌جای پیام «سامانه کار نمی‌کند»، یک بسته شواهد آماده کنید:
| مدرک | چه چیزی ثبت شود | ملاحظه امنیتی |
| متن کامل خطا | پیام خام، نام فیلد و زمان | اطلاعات شخصی پوشانده شود |
| شناسه‌ها | شماره مالیاتی و شناسه درخواست | کلید و توکن کامل ارسال نشود |
| وضعیت صورتحساب | نتیجه استعلام و زمان آن | از کارپوشه درست استخراج شود |
| مشخصات محیط | نسخه نرم‌افزار، روش ارسال و شعبه | رمز و کلید خصوصی حذف شود |
| نمونه داده | یک رکورد حداقلی بازتولیدپذیر | داده واقعی حساس ناشناس شود |
| سابقه اقدام | تلاش‌های قبلی و شماره تیکت | ترتیب زمانی بدون دستکاری حفظ شود |
کلید خصوصی، رمز، توکن کامل، اطلاعات بانکی و داده شخصی خریدار را در تیکت عمومی منتشر نکنید. اطلاعات حساس را پوشانده و فقط از کانال امن مورد توافق استفاده کنید. سازمان امور مالیاتی برای همه نرم‌افزارهای حسابداری بازار مجوز محصول صادر نمی‌کند؛ بنابراین ادعای تبلیغاتی «مورد تأیید» جای بررسی قرارداد پشتیبانی، مسئولیت‌ها و سازگاری با اسناد جاری را نمی‌گیرد.
چه زمانی اصلاح نکنیم و موضوع را ارجاع دهیم؟
– صورتحساب در سامانه پذیرفته شده اما نرم‌افزار آن را ناموفق نشان می‌دهد.
– سند مرجع چند مرحله اصلاح یا ابطال دارد و زنجیره آن روشن نیست.
– تغییر موردنیاز به هویت طرفین، اصل معامله یا دوره مالیاتی مربوط است.
– نرخ یا شناسه کالا/خدمت با وضعیت فراخوان و پرونده تعارض دارد.
– خطا به حد مجاز فروش مربوط است؛ این موضوع در مقاله مستقل ردیف ۱۶ بررسی می‌شود.
– اختلال فنی باعث عبور از مهلت یا تاثیر بر اظهارنامه شده است.
در این موارد، اقدام آزمایشی روی سند واقعی می‌تواند ریسک را بیشتر کند. نسخه پشتیبان، لاگ و مدارک را حفظ کنید و ابتدا وضعیت پرونده و دستورالعمل جاری را بررسی نمایید.
چک‌لیست پیشگیری از خطا
– اطلاعات پرونده، شعبه و حافظه مالیاتی به‌صورت دوره‌ای همگام می‌شود.
– نسخه اسناد فنی و الگوهای نرم‌افزار ثبت و به‌روز است.
– ساعت سرور و منطقه زمانی کنترل می‌شود.
– شناسه کالا/خدمت و نرخ از مرجع جاری خوانده می‌شود.
– محاسبات ردیف و کل پیش از ارسال اعتبارسنجی می‌شود.
– شماره منحصر به فرد مالیاتی دستی و تکراری تولید نمی‌شود.
– برای درخواست‌های ناموفق، ابتدا وضعیت استعلام می‌شود.
– ارسال دسته‌ای گزارش ردیفی پذیرفته/ردشده دارد.
– کلیدها و اطلاعات حساس در لاگ عمومی ذخیره نمی‌شوند.
– فرایند اعلام نقص فنی موضوع ماده ۱۲ از قبل مستند شده است.
پرسش‌های متداول
خیر، نه پیش از استعلام. اگر درخواست نخست ثبت شده باشد، ارسال دوباره می‌تواند تکرار ایجاد کند. ابتدا وضعیت همان شماره مالیاتی یا شناسه درخواست را بررسی کنید.
نرم‌افزارها ممکن است پاسخ رسمی را به شکل‌های متفاوت نمایش دهند. متن خام پاسخ، نام فیلد و شناسه درخواست برای تشخیص دقیق‌تر از عنوان کوتاه رابط کاربری مهم‌تر است.
لزوماً نه. نوع صورتحساب، شناسه خریدار، وضعیت پردازش و کارپوشه انتخاب‌شده باید بررسی شود. انواع فاقد اطلاعات خریدار به کارپوشه او منتقل نمی‌شوند.
طبق مقرره مورد بررسی در رأی شماره ۲۳۱۳۰۲۶، از ۱۴۰۳/۰۸/۱۵ فاصله ۱۲ روز اعلام شده است. چون تنظیمات اجرایی قابل تغییرند، نسخه فعال دستورالعمل در تاریخ ارسال نیز باید کنترل شود.
رخداد و فروش‌های متاثر را مستند کنید و طبق ماده ۱۲، تا پایان روز اداری بعد از مسیر اعلامی موضوع را اطلاع دهید. ثبت و ارسال بعدی نیز باید مطابق دستورالعمل جاری انجام شود.
این کار توصیه نمی‌شود. تغییر صوری داده ممکن است سند را با واقعیت معامله و زنجیره شماره‌ها ناسازگار کند. علت اصلی باید اصلاح شود.
خیر. حد مجاز یک قاعده قانونی/اعتباری موضوع ماده ۶ است و آثار آن با خطای قالب یا اتصال فرق دارد. بررسی تفصیلی آن باید در راهنمای مستقل انجام شود.
جمع‌بندی
رفع خطای سامانه مؤدیان از حدس‌زدن کد خطا شروع نمی‌شود؛ از تشخیص مرحله شکست آغاز می‌شود. ابتدا معلوم کنید صورتحساب واقعاً رد شده، در حال پردازش است یا فقط پاسخ آن به نرم‌افزار نرسیده است. سپس اطلاعات پایه، نوع و الگو، شناسه‌ها، محاسبات، تاریخ، سند مرجع و تنظیمات امنیتی را با نسخه جاری اسناد کنترل کنید.
اگر اختلال، مهلت، نرخ، هویت طرفین یا زنجیره اسناد را تحت تاثیر قرار داده، پیش از ارسال مجدد پرونده را بررسی کنید. می‌توانید برای ارزیابی مستندات از صفحه تماس پیشگامان مالیات استفاده کنید؛ هیچ نتیجه‌ای بدون مشاهده داده و وضعیت واقعی سامانه قابل تضمین نیست.
